RFC8986 describes the End.DT2U behavior as "Endpoint with decapsulation and
unicast MAC L2 table lookup". However, its definition includes the
instruction for forwarding BUM traffic.
S01. If (Upper-Layer header type == 143(Ethernet) ) {
S02.Remove the outer IPv6 header with all its exten
So, using the new ethertype inside a (closed/open) domain would require all
IPv6 routers inside the domain to support SRv6 or at least support the new
ethertype to check if any IPv6 packet containing an SRH was received with
this ethertype? If an IPv6 router supports neither, then one cannot enable
e the new ethertype if you want to use
> this solution. For some operators, that is a show stopper and they will
> not use this capabilities. For others, it is quite deployable, and even
> helpful in keeping control of what servicces are offered where.
>
> Yours,
>
> Joel
> On
draft-ietf-spring-sr-yang seems to describe Maximum SID Depth (MSD) as a
read-write attribute that is configurable on the node, but I really wonder
how many vendors actually support changing the MSD on a node.
Suppose a node is capable of pushing a maximum of K labels in h/w and the
node MSD is co
unnel could
> exit over different line cards. Per node MSD limits computation to the
> lowest value supported by the node.
>
Agree, this becomes really tricky with a router supporting different NPU
types/generations, so node MSD is one thing a PCE can rely on for sure..
Regards,
Muthu
>
&
neration NPU, depending
> on revision, MSD supported could vary drastically, routers with 3
> generations of line cards are not an exception either, so MSD per
> adj/interface is a rather valuable information to a PCE if a tunnel could
> exit over different line cards. Per node MSD lim
ense of the number of LSP out segments that the
> device can support.
>
>
>
>
>
> Hope this helps.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell: +972-549266302 <+972%2054-926-6302>
>
&g
ly support it this way. My
understanding is that BCM supports only a fixed maximum impossible label
stack depth on a packet.
Regards,
Muthu
>
>
> Hope this clarifies my position.
>
>
>
> Regards,
>
>
> Sasha
>
>
>
> Office: +972-39266302Muthu,
-offs, some of them quite ingenious.
>
> Again, the IETF mailing list is not the right place for discussing actual
> data path implementations IMHO.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell: +972-5
i.e., there will be no SR traffic
> engineering at all.
>
>
>
> Hopefully this addresses your concerns.
>
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell: +972-549266302 <+972%2054-926-6302>
>
> Em
Using end-to-end path protection together with local protection can result
in traffic loops. Consider the foll. topology:
B-C
|/ \
| / \
| / \
| / \D+
A/ Z (CE)
\ F+
\ /
\ /
\ /
\E/
- All links are of equal cost.
- A,
e2e path protection and local
protection are used together with RSVP-TE?
Regards,
Muthu
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell: +972-549266302 <+972%2054-926-6302>
>
> Email: alexander.vainsht
gt;
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell: +972-549266302 <+972%2054-926-6302>
>
> Email: alexander.vainsht...@ecitele.com
>
>
>
> *From:* Muthu Arul Mozhi Perumal [mailto:muthu.a...@gmai
it can introduce other
problems to solve.
Regards,
Muthu
>
>
> Regards,
>
> Sasha
>
>
>
> Office: +972-39266302 <+972%203-926-6302>
>
> Cell: +972-549266302 <+972%2054-926-6302>
>
> Email: alexander.vainsht...@ecitele.com
>
>
&
14 matches
Mail list logo
