Re: [mpls] MPLS-RT review of [e-mail]

[Lizhong Jin<[e-mail]>]

Hi Pranjal,

> Hi Lizhong,
> 
> ¡°Then does the LDP multiple instance in this draft does not 
> include the VRF case? It is better to explicit describe this, 
> otherwise it is confusing. In the VRF case, the FEC will be 
> duplicated between different instances.¡±
> 
> [Pranjal] The multiple instances are within VRF. Sure, will clarify 
> explicitly.
[Lizhong] to confirm I understand correctly. Do you mean the multiple 
instances in this draft does not include the VRF case? And multiple 
instances are belong to only one VRF, right?

> 
> ¡°If the FEC set (identified by capability) is totally 
> disjoint between two instance, it could be simply discard the FEC 
> label mapping if not match capability to avoid loop, why we still 
> need Node-ID TLV£¿¡±
> 
> [Pranjal] Node-ID TLV is a generic construct and not associated with FEC 

> capability. If peer hasn¡¯t implemented FEC capability then you may need 

> some way to figure out. Secondly, even though peer supports FEC 
capability,
> it is useful to know that we are running || sessions to same peering 
system.
[Lizhong] If peer does not support FEC capability, you should have some 
local configuration to indicate the FEC set. Then you could still avoid 
loop by this local indication. I am trying to see the technical motivation 
of Node-ID TLV. If we only want to know the same peering relationship for 
easy management, the NMS could simply do that. Is there any other 
technical reason for Node-ID TLV?

Thanks
Lizhong

> 
> Thanks,
> Pranjal
> 
> 
> 
> From: Lizhong Jin [mailto:[e-mail]] 
> Sent: Monday, September 03, 2012 6:48 PM
> To: Dutta, Pranjal K (Pranjal)
> Cc: [e-mail]; mpls@ietf.
> org; [e-mail]; Dutta, Pranjal K (Pranjal)
> Subject: RE: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-
> [e-mail]
> 
> 
> Hi Pranjal, 
> Much clear now, thank you. Two inline comments that maybe missed in 
> your previous email. 
> 
> snip from previous email... 
> > 2. For LDP multiple instance, is it allowed for duplicated FEC 
> > between two instance? 
> > 
> > [Pranjal] Duplicated FECs won¡¯t be allowed. The parallel sessions 
> > between two peering systems needs to be disjoint with respect to the 
> > working set 
> > ¨C the FECs. This needs to be ensured thru various FEC specific 
> > session capabilities. Each || session must advertise disjoint FEC 
> > capabilities. Section 
> > 2.1.1 explains the use of LDP session capabilities (RFC5561) to keep 
> > the FEC distribution mutually exclusive. What criteria to be used 
> > for segregation 
> > of FECs are to be decided on case to case basic. This draft provides 
> > the fundamental building block for control plane fate separation. 
> [Lizhong] Then does the LDP multiple instance in this draft does not 
> include the VRF case? It is better to explicit describe this, 
> otherwise it is confusing. In the VRF case, the FEC will be 
> duplicated between different instances. 
> 
> > 
> > 3. If duplicated FECs are possible between two instance, receiving 
> > same label mapping from parallel multi-lsr peering sessions could 
> > not interpret as loop, right? 
> > 
> > [Pranjal] Duplicated FECs are not allowed across . But what if a 
> > peering system misbehaves or peering system not supporting the 
> > solution (thus agnostic 
> > Of the fact that a few sessions are terminated in same peering 
> > system) leaks FECs on all || sessions? That may result in a loop for 
> > some applications 
> > and ¡°Section 3. Detection of multi-instance peering¡± addresses that 
> > issue.  It lets a system aware of || sessions and thus can take 
> > necessary actions. 
> [Lizhong] If the FEC set (identified by capability) is totally 
> disjoint between two instance, it could be simply discard the FEC 
> label mapping if not match capability to avoid loop, why we still 
> need Node-ID TLV£¿ 
> 
> Thanks 
> Lizhong 
> 
> 
> "Dutta, Pranjal K (Pranjal)" <[e-mail]> 
> wrote 2012/09/01 01:38:39:
> 
> > Hi Lizhong, 
> >                      I think I didn¡¯t clarify on ¨C ¡°Do you mean the 

> > two instance need to synchronize FEC mapping information¡±. The 
> > multi-instance peering that we described about 
> > Is a little different from multi-instance IGPs. In multi-instance 
> > LDP case by default the FEC database would be shared in the sense 
> > that all label mapping would share the same 
> > global label space and thus following is possible/desirable. 
> > 
> >                           System A 
> > System B                                 System C 
> >                               LSR-A1----------------------------LSR-
> > B1    X    LSR-B3--------------------------LSR-C1 
> >                               LSR-A2 ---------------------------LSR-
> > B2    X    LSR-B4--------------------------LSR-C2 
> > 
> > 
> >                      There can be a seamless LSP/Tunnel between 
> > System A and System C for FEC F1. C->B label mapping L1 is exchanged
> > using B3-C1 LSR tuples and 
> > B->A label mapping L2 is exchanged using B2-A2 LSR tuples. This is 
> > because the FEC-Label mapping database continue to exist in systemB in 
same 
> > way as it does today. There would be only one FEC F1 in the LIB : 
> > 
> > 
> > F1  --> egress label L1 (Local LSR B3---Remote LSR C1) 
> >   -¨¤
> > ingress label L2 (Local LSR B2---Remote LSR A2) 
> > 
> >                      The X connect at system B is L1->L2 
> > 
> > 
> > 
> > Thanks, 
> > Pranjal 
> > 
> > From: [e-mail] [mailto:[e-mail]] On Behalf 
Of 
> > Dutta, Pranjal K (Pranjal)
> > Sent: Friday, August 31, 2012 10:22 AM
> > To: Lizhong Jin
> > Cc: [e-mail]; [e-mail]; draft-pdutta-mpls-
> > [e-mail]
> > Subject: Re: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-
> > [e-mail] 
> > 
> > Hi Lizhong, 
> >                         Please refer my answers inline. 
> > Thanks, 
> > Pranjal 
> > 
> > 
> > From: Lizhong Jin [mailto:[e-mail]] 
> > Sent: Thursday, August 30, 2012 11:42 PM
> > To: Dutta, Pranjal K (Pranjal)
> > Cc: [e-mail]; mpls@ietf.
> > org; [e-mail]
> > Subject: RE: [mpls] MPLS-RT review of draft-pdutta-mpls-multi-ldp-
> > [e-mail] 
> > 
> > 
> > Hi Pranjal, 
> > Thanks for the clarification, much clear than before for me now. 
> > Please see inline for addtional comments. 
> > 
> > One more question for section 3. 
> > "When a LSR receives a FEC label mapping from a peering session but 
> > same FEC mapping has been already receiver over another peering 
> > session associated with same Node-ID then the receiving LSR MUST 
> > send a Label Release to the peering session with statuc code" 
> > How a LSR could know the FEC mapping information from another 
> > instance? Do you mean the two instance need to synchronize FEC 
> > mapping information? 
> > 
> > [Pranjal] One way to think is  as follows ¨C let¡¯s say that detection
> > of multi-instance peering is implemented as in Section 3. Then 
> > receiving system would know about the sessions terminating 
> > in same remote peering system. So the receiving system can create a 
> > group/bundle id internally for all such || sessions and keep the 
> > FEC-label mappings also in the database. If there is a 
> > collision of Fec label mappings in the group-id database then label 
> > release can be sent, keeping the first one intact. 
> > 
> > 
> > Thanks 
> > Lizhong 
> > 
> > "Dutta, Pranjal K (Pranjal)" <[e-mail]> 
> > wrote 2012/08/31 01:00:53:
> > 
> > > 2. For LDP multiple instance, is it allowed for duplicated FEC 
> > > between two instance? 
> > > 
> > > [Pranjal] Duplicated FECs won¡¯t be allowed. The parallel sessions 
> > > between two peering systems needs to be disjoint with respect to the
> > > working set 
> > > ¨C the FECs. This needs to be ensured thru various FEC specific 
> > > session capabilities. Each || session must advertise disjoint FEC 
> > > capabilities. Section 
> > > 2.1.1 explains the use of LDP session capabilities (RFC5561) to keep
> > > the FEC distribution mutually exclusive. What criteria to be used 
> > > for segregation 
> > > of FECs are to be decided on case to case basic. This draft provides
> > > the fundamental building block for control plane fate separation. 
> > [Lizhong] Then does the LDP multiple instance in this draft does not
> > include the VRF case? It is better to explicit describe this, 
> > otherwise it is confusing. In the VRF case, the FEC will be 
> > duplicated between different instances. 
> > 
> > > 
> > > 3. If duplicated FECs are possible between two instance, receiving 
> > > same label mapping from parallel multi-lsr peering sessions could 
> > > not interpret as loop, right? 
> > > 
> > > [Pranjal] Duplicated FECs are not allowed across . But what if a 
> > > peering system misbehaves or peering system not supporting the 
> > > solution (thus agnostic 
> > > Of the fact that a few sessions are terminated in same peering 
> > > system) leaks FECs on all || sessions? That may result in a loop for
> > > some applications 
> > > and ¡°Section 3. Detection of multi-instance peering¡± addresses 
that 
> > > issue.  It lets a system aware of || sessions and thus can take 
> > > necessary actions. 
> > [Lizhong] If the FEC set (identified by capability) is totally 
> > disjoint between two instance, it could be simply discard the FEC 
> > label mapping if not match capability to avoid loop, why we still 
> > need Node-ID TLV£¿ 
> > 
> > > 
> > > 4. In case 1~4, one interface will serve multiple instance, I guess,
> > > the interface you refer is physical interface, and when sharing one 
> > > physical interface, then one sub-interface for each instance is 
> > > still required, right? In my understanding, one IP interface could 
> > > not be shared by multiple LDP instance, otherwise how to treat the 
> > > prefix of that interface. 
> > 
> > > [Pranjal] I won¡¯t view it as sub-interface since all instances are 
> > > running in same FEC database. So if we think from a ¡°virtual router
¡±
> > > point of view (each 
> > > Virtual Router is separated across all verticals in RIB/LFIB/FIB and
> > > self-sufficient) then all the multiple LSR instances would be 
> > > running within same 
> > > Virtual Router and thus can share interfaces assigned to that 
> > > Virtual Router. Although the draft does not prevent usage of same 
> > > Interface across all LSRs 
> > > in practice it is desirable to fate separate the physical topology 
> > > to achieve separation across entire vertical. Separation of physical
> > > topology can be 
> > > achieved by LDP Multi-topology that synchronizes IGP and LDP¡¯s view 
(
> > > http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-04) or
> > > by using hello 
> > > adjacency capabilities at LDP level (http://tools.ietf.
> > > org/html/draft-pdutta-mpls-ldp-adj-capability-00). 
> > > 
> > > 
> > > Hope to see your clarification. Thanks. 
> > > 
> > > Lizhong 
> > > 
> > > 
> > > Loa Andersson <[e-mail]> wrote 2012/08/29 17:10:01:
> > > 
> > > > Kamran. Eric and Lizhong,
> > > > 
> > > > You have been selected as an MPLS Review team reviewers for
> > > > draft-pdutta-mpls-multi-ldp-instance-00.txt.
> > > > 
> > > > Note to authors: You have been CC¡¯d on this email so that you can 
know
> > > > that this review is going on. However, please do not review your 
own
> > > > document.
> > > > 
> > > > Reviews should comment on whether the document is coherent, isit 
useful
> > > > (ie, is it likely to be actually useful in operational networks), 
and is
> > > > the document technically sound?  We are interested in knowing 
whether
> > > > the document is ready to be considered for WG adoption (ie, it 
doesn¡¯t
> > > > have to be perfect at this point, but should be a good start).
> > > > 
> > > > Reviews should be sent to the document authors, WG co-chairs and
> > > > secretary, and CC¡¯d to the MPLS WG email list. If necessary, 
comments
> > > > may be sent privately to only the WG chairs.
> > > > 
> > > > Are you able to review this draft by Sep 13, 2012?
> > > > 
> > > > Thanks, Loa
> > > > (as MPLS WG chair)
> > > > -- 
> > > > 
> > > > 
> > > > Loa Andersson                         email: 
[e-mail]
> > > > Sr Strategy and Standards Manager            [e-mail]
> > > > Ericsson Inc                          phone: [phone]
> > > >                                               [phone]
> > > >