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

["Dutta, Pranjal K (Pranjal)" <[e-mail]>]

Hi Lizhong,

                      Pls. refer inline to your questions.

[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?

Doesn¡¯t each VRF uses its own LSR-ID/Router-ID today? Each VRF is an independent LDP stack. We are not saying that ¡°don¡¯t use different LSR-ID
across VRFs¡±. The draft brings the case for multiple LSR within a VRF which is not the case today.

[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?

Node-ID TLV is not limited to loop detection in FEC exchanges. By configuration/NMS we can do many things ¨C even static MPLS
without needing LDP or signaling at all (e.g We shouldn¡¯t have notion of ¡°ldp discovery¡±). Since the context of this draft is a signaling protocol, so
Node-ID TLV serves as an indication for || sessions. Inclusion of Node ID TLV is optional and is not mandatory as mentioned in the draft. Sessions are
part of infrastructure based on which various applications are built upon and an application may find utility if it is known that a set of sessions are ||
to same node.

Thanks,
Pranjal

________________________________
From: Lizhong Jin [mailto:[e-mail]]
Sent: Monday, September 03, 2012 8:53 PM
To: Dutta, Pranjal K (Pranjal)
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [mpls] MPLS-RT review of [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]
> > > >