[KT] Actually, we would still have two NLRIs since the descriptors for Pe= erAdj SID is different from PeerNode SID as per the BGP-LS EPE draft.<= /o:p>

2.  BGP-LS Extensions for SRv6
   o  SRv6 End.X SID of the link state routing adja=
cency or the BGP EPE
      Peer Adjacency is advertised via a =
new SRv6 End.X SID TLV
7.2.  SRv6 BGP Peer Node SID TLV
   The BGP Peer Node SID and Peer Set SID for SR with MP=
LS dataplane are
   specified in [I-D.ietf-idr-bgpls-segment-routing-epe]=
.  The similar
   Peer Node and Peer Set SID functionality can be reali=
zed with SRv6
   using the END.X SRv6 SID.  The =
SRv6 BGP Peer Node SID TLV is an
   optional TLV for use in the BGP-LS Attribute for=
 an SRv6 SID NLRI
   corresponding to BGP protocol.=
  This TLV MUST be included along with
   SRv6 End.X SID that is associated with the BGP Peer N=
ode or Peer Set
   functionality.
6.  SRv6 SID NLRI

   A new "Link-State NLRI Type" is defined for=
 SRv6 SID information as
   following:

   o  Link-State NLRI Type: SRv6 SID NLRI (value TB=
D see IANA
      Considerations Section 8.1).
     0      &nbs=
p;            1 =
;            &n=
bsp;     2       &nb=
sp;           3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0=
 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+=
-+
    |  Protocol-ID  |
    +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=

    |       &nbs=
p;            &=
nbsp;   Identifier        =
;            &n=
bsp;        |
    |        &nb=
sp;            =
   (64 bits)        =
            &nb=
sp;         |
    ++-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-=
3;-+-+-+-+-+-+-+-+-+-+-+-+|=

    |       &nbs=
p;       Local Node Descriptors (variable)&nb=
sp;            =
 //
    +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=

    |       &nbs=
p;       SRv6 SID Descriptors (variable) =
;            &n=
bsp;  //
    +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-&#=
43;-+-+-+-+-+-+-+-+-+-+-+-+=

           =
           Figure 11: SRv=
6 SID NLRI Format
  &n=
bsp;  //
Here defined the SRv6 SID NLRI=
. If we use this NLRI, when we have more than one peer node,
   W=
e may construct routes with:
   R=
oute1: SRv6 SID NLRI1 (Local Node Desc + SID1) + Peer Node SID (pee=
r1) + other Attr Tlv
   R=
oute2: SRv6 SID NLRI2 (Local Node Desc + SID2) + Peer Node SID (pee=
r2) + other Attr Tlv
   W=
hy do we have to change to this?
What are the benefits of this =
change?

   F=
or draft draft-ietf-idr-bgpls-segment-routing-epe, the route will be
   R=
oute1: Link NLRI1(Local Node Desc + peer1) + Peer Node SID (peer1) =
+ other Attr Tlv
   R=
oute2: Link NLRI2(Local Node Desc + peer2) + Peer Node SID (peer2) =
+ other Attr Tlv

  &n=
bsp;  Also in this format, when a peer join a peer set, how to create =
the route? Perhaps=1B$B!'=1B(B=

   R=
oute1: SRv6 SID NLRI1 (Local Node Desc + SID1) + Peer Node SID (pee=
r1) + other Attr Tlv
   R=
oute2: SRv6 SID NLRI1 (Local Node Desc + SID2) + Peer Node SID (S-f=
lag) + other Attr Tlv
   W=
hat=1B$B!G=1B(Bs
 the relationship about the two routes ?
   I=
f there exist a route3:
   R=
oute3: SRv6 SID NLRI1 (Local Node Desc + SID3) + Peer Node SID (S-f=
lag) + other Attr Tlv
   N=
ow the Peer node route1 belongs to route2=1B$B!G=1B(Bs
 Peer Set or route3=1B$B!G=1B(=
Bs Peer Set?=

   B=
ut it=1B$B!G=1B(Bs
 clear for old mpls epe draft:
   R=
oute1: Link NLRI1(Local Node Desc + peer1) + Peer Node SID (peer1) =
+ Peer Set Sid(set1)+other Attr Tlv
   R=
oute2: Link NLRI2(Local Node Desc + peer2) + Peer Node SID (peer2) =
+ Peer Set Sid(set1)+ other Attr Tlv

Best Regards
Haibo=

           The following is an example

           PE1----ABR1-----ABR2-----PE2

           PE1 will send the following labels with a color 100 path

           [2001 13001 801 16], where

           2001 - SR label to reach ABR1

           13001 - Binding-SID label to reach ABR2. Underlying tunnel type =
is RSVP-TE

           801 - Binding-SID label to reach PE2. Underlying tunnel type is =
SR-TE

           16 - a VPN label
           ^^^^^^^^^^^^^^^^

Many thx,

Robert.

 Using the method defining in this draft, the ISP=
 AS64597 needs to
   setup only one "Destination Origin AS + Source Prefix" rule=
 in Router
   R1 as following:

     +--------------+--------------+-------------------------+
     | Destination  | Source Prefix| Redirect to IP Nexthop  |
     | IP Origin AS |              |                         |
     +--------------+--------------+-------------------------+
     |  64598       | IP Prefix 61 |       R3                |
     +--------------+--------------+-------------------------+

     Figure 3: Steering the Traffic Using Origin AS and Source Prefix
“   There is one special case: the Tunnel Endpo=
int sub-TLV MAY have a
In case of any error detected, either
=C2=A0=C2=A0 at the attribute or its TLV/s=
ub-TLV level, the "treat-as-withdraw"
=C2=A0=C2=A0 strategy of [RFC7606] MUST be applied.
In case of any error detected, either
=C2=A0=C2=A0 at the attribute or its TLV/s=
ub-TLV level, the "treat-as-withdraw"
=C2=A0=C2=A0 strategy of [RFC7606] MUST be applied.

In case of any error detected, either
=C2=A0=C2=A0 at the attribute or its TLV/s=
ub-TLV level, the "treat-as-withdraw"
=C2=A0=C2=A0 strategy of [RFC7606] MUST be applied.
The value 2 pre=
viously corresponded to the IPv6 SID TLV which was
   specified in previous versions of thi=
s document.  It was removed an=
d
   usage of the BGP Prefix-SID for Segme=
nt Routing over the IPv6
   dataplane [I-D.ietf-spr=
ing-segment-routing] has been deferred to
   future =
specifications.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

Name	Comments	Notes
Cheng Li	We will update the draft to suppo= rt multiple bidirectional path in ECMP by copying weight TLV to SR Bidir pa= th sub-TLV in the near future.	Next revision<= /o:p>
Linda Dunbar	draft-li-idr-bgp-ls-sr-policy-pat= h-segment-03 has a statement in the Abstract stating that the document is t= o define ways for collecting configuration and states of SR policies by BGP-LS. So, it really not SR Policies Extensi= ons (as stated in the title), is it?	Will check the name
Why not have a separate name to r= epresent the "resource or attributes" of the path?
Aijun Wang	Can these two drafts be merged in= to one?
Dhruv Dhody	https://mailarchiv= e.ietf.org/arch/msg/idr/2Z7bjxLELWLosG9ryuR2vpwiB-0
Tianran Zhou	Here are some editorial nits are:= 1. in abstract: unidirctional -&g= t; unidirectional 2. in introduction: carriying -&g= t; carrying 3. in section 3: idendifying ->= ; identifying 4. in section 4: Bidirectioanl -&= gt; Bidirectional 5. in section 5: beyong -> bey= ond; receiption -> reception And it's better to give some init= ial security considerations in this draft.
Ketan Talaulikar	https://mailarc= hive.ietf.org/arch/msg/spring/CyaI2IfkUOnc0lGIe3rdbijYhpQ
Susan Hares	I expect from the authors to send= an email to IDR with the following: a) &= nbsp; a summary of comments received on WG adoption call, b) = Plans for refining and progressing their drafts, and c) &= nbsp; status of any implementations.