Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05

["Zhenlong Cui" <[e-mail]>]

Hi Eric,

Sorry, protocol redundancy is what I had in mind when I wrote my original mail.

I didn't understand why to define a different behavior for "destination node identifier" and "destination interface identifier".

In a P2MP scenario, an intermediate node may send multiple responses Which include different return codes (per-interface MIP case).

I do understand the draft contains no such requirements for the for P2MP case.
Essentially, the requestor receiving multiple responses which include different return code may not be a problem.

Lastly, I think this issue might be discussed in the draft-farrel-mpls- tp-mip-mep-map, not here.


Thanks for your response.

> -----Original Message-----
> From: Eric Gray [mailto:[e-mail]]
> Sent: Thursday, July 28, 2011 12:45 AM
> To: Zhenlong Cui; 'Sam Aldrin'
> Cc: [e-mail]; [e-mail]
> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> 
> Not sure why you think the protocol redundancy is necessary,
> or even a good idea.
> 
> The DSMAP TLV as defined allows specification of an interface.
> 
> Asking for a potentially new TLV that will also provide this
> information in the event that one is unable to handle, read or
> interpret the DSMAP TLV is pointless.  If one cannot use one
> TLV, the chances are very good that one cannot use a newer one
> either.
> 
> -----Original Message-----
> From: Zhenlong Cui [mailto:[e-mail]]
> Sent: Wednesday, July 27, 2011 10:46 AM
> To: 'Sam Aldrin'; Eric Gray
> Cc: [e-mail]; [e-mail]
> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> Importance: High
> 
> Hi Sam and Eric,
> 
> Ok, I understand that the issue of unknown TLVs is outside the scope of this document.
> 
> > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV.
> > > 1) Which return code to send when source/destination identifiersare wrong or drop the request.
> > As said above, it should be dropped, if the source is unknown.
> 
> OK, I think this is clear now:
> - A responder will drop requests from an unknown source.
> - A responder will drop requests in case of destination identifier mismatch. (as defined in section 4.2.3.)
> 
> > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request.
> > Return code 5, dsmap mismatch. This is already defined in rfc4379.
> 
> Regarding the identifiers of nodes and interfaces for route trace which are defined in RFC 5860 as below.
> The information collected MUST include identifiers related to the nodes and interfaces composing that route.
> 
> I think "destination node identifier" and "destination interface identifier" are composed for one maintenance entity,
> therefore they
> should have the same behavior in the responder.
> 
> So, my suggestions regarding these issues are as follows.
> 1) It should be dropped, if the identifier of the DSMAP TLV is wrong.
> 2) If not, the "interface identifier" should be included in the Destination identifier TLV, or one might define a new TLV.
> 
> 
> Best,
> Zhenlong
> 
> > -----Original Message-----
> > From: Sam Aldrin [mailto:[e-mail]]
> > Sent: Wednesday, July 27, 2011 6:29 AM
> > To: Zhenlong Cui
> > Cc: Eric Gray; [e-mail]; [e-mail]
> > Subject: Re: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> >
> > As Eric said in earlier email, these questions are more related to RFC4379 and not just this draft.
> > Having said that, please find responses inline.
> >
> > Sam
> >
> > Sent from my iPad
> >
> > On Jul 26, 2011, at 2:03 PM, "Zhenlong Cui" <[e-mail]> wrote:
> >
> > > Hi Eric,
> > >
> > > I remember you said earlier that you should drop the packet from unknown source nodes, because there is a security problem
> > with
> > > responding.
> > > On the other hand, you say that you should send a reply when the request includes an unknown TLV.
> > >
> > Unknown source is not same as receiving malformed Tlv or unsupported tlv.
> > > I think if the responder receives a request it checks the type of the TLV before it checks the identifiers.
> > >
> > > So, my question is "if the responder receives a request from an unknown source node that includes an unknown TLV, does
> > the responder
> > > have to reply to the unknown source node?". If yes, this has the security problem you mentioned earlier, doesn't it?
> > If received from unknown source, most vendors drop the packet.
> > >
> > >
> > > Lastly, I suggest that add some mention to this draft regarding responder's behavior for new TLV.
> > > 1) Which return code to send when source/destination identifiers are wrong or drop the request.
> > As said above, it should be dropped, if the source is unknown.
> > > 2) Which return code to send when ingress if_num/egress if_num of DSMAP TLV are wrong or drop the request.
> > Return code 5, dsmap mismatch. This is already defined in rfc4379.
> > >
> > >
> > > Best,
> > > Zhenlong
> > >
> > >> -----Original Message-----
> > >> From: Eric Gray [mailto:[e-mail]]
> > >> Sent: Wednesday, July 27, 2011 12:56 AM
> > >> To: Zhenlong Cui
> > >> Cc: [e-mail]; [e-mail]
> > >> Subject: RE: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> > >>
> > >> Zhenlong,
> > >>
> > >> Q-1: See RFC 4379, where these regitry entries are derived from.
> > >>     RFC 4379 sets up a number of registries - including the TLV
> > >>     registry - and defines explicitly how to handle unknown TLV
> > >>     types in section 3, in two very obscure paragraphs on page
> > >>     10, just before section 3.1.
> > >>
> > >> Q-2: "ingress port" is not correct - thanks for spotting this
> > >>     cut-and-paste duplication error.
> > >>
> > >> --
> > >> Eric
> > >>
> > >> -----Original Message-----
> > >> From: Zhenlong Cui [mailto:[e-mail]]
> > >> Sent: Tuesday, July 12, 2011 5:20 AM
> > >> To: [e-mail]; [e-mail]
> > >> Subject: [mpls] Questions for draft-ietf-mpls-tp-on-demand-cv-05
> > >>
> > >> Dear Authors,
> > >>
> > >> Two questions regarding the idenfifiers TLV and DSMAP TLV.
> > >>
> > >> Question 1:
> > >>>>> Which return code to send when identifiers are wrong (Malformed echo
> > >>>>> request received?) or drop the packet.
> > >>>>>
> > >>>>> EG > Drop the packet, probably log the error, possibly run off
> > >>>>> EG > screaming into the night.  What does one do when one gets
> > >>>>> EG > something either not recognizably intended for one, or not
> > >>>>> EG > from a source that one recognizes?  From a security point
> > >>>>> EG > of view, we cannot require an implementation to reply to
> > >>>>> EG > the requester in this case (this is an attack vector for
> > >>>>> EG > all kinds of hate and discontent).  Nor can we forbid it.
> > >>>>>
> > >> If the "type" of identifier TLV is incorrect, then should this request frame be dropped? Should we reply to the requestor(One
> > >> or
> > >> more of the TLVs was not understood)? Can this way two answers be generated?
> > >>
> > >>
> > >> Question 2:
> > >> In section 2.1.1, Is below("ingress port") correct?
> > >>
> > >>   Egress IF_Num identifies the ingress port on the target node.  A
> > >>   value of 0 indicates that the port is not part of the identifier.
> > >>
> > >>
> > >> Best,
> > >> zhenlong
> > >>
> > >>> -----Original Message-----
> > >>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Rolf Winter
> > >>> Sent: Monday, June 27, 2011 8:04 PM
> > >>> To: Eric Gray; [e-mail]; [e-mail]
> > >>> Subject: Re: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-cv
> > >>>
> > >>> I think that's OK, since the value is not beyond but within the TLV. Taken from 4379:
> > >>>
> > >>> Types are defined below; Length is the length of the Value field in
> > >>> octets.  The Value field depends on the Type; it is zero padded to
> > >>> align to a 4-octet boundary.
> > >>>
> > >>> That means the length is the length of the actual value (excluding the padding). So the beginning of the next TLV is
> > determined
> > >>> by the length plus a value that makes it align on a 4-octet boundary (which of course can be 0). I cannot follow your
> > argument
> > >>> why this is not correct. I am sure I am missing something trivial, so sorry for spamming the list. But all information
> > >> is
> > >>> encoded in the packet (plus the simple rule quoted above). Otherwise, a node needs to understand the internal structure
> > >> of
> > >>> each TLV to extract the value instead of applying the simple rule above.
> > >>>
> > >>>
> > >>> Best,
> > >>>
> > >>> Rolf
> > >>>
> > >>>
> > >>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014
> > >>>
> > >>>
> > >>>> -----Original Message-----
> > >>>> From: Eric Gray [mailto:[e-mail]]
> > >>>> Sent: Montag, 27. Juni 2011 12:42
> > >>>> To: Rolf Winter; [e-mail]; draft-ietf-mpls-tp-on-demand-
> > >>>> [e-mail]
> > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > >>>> cv
> > >>>>
> > >>>> IMO, that would be a problem with RFC 4379.  Perhaps there is
> > >>>> an errata?
> > >>>>
> > >>>> TLVs are meant to follow each other, where the beginning of the
> > >>>> next TLV is determined by the length of the current TLV - hence
> > >>>> it is not correct to specify any content as having any value at
> > >>>> all if it is beyond the end of the TLV.
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Rolf Winter [mailto:[e-mail]]
> > >>>> Sent: Monday, June 27, 2011 5:06 AM
> > >>>> To: Eric Gray; [e-mail]; draft-ietf-mpls-tp-on-demand-
> > >>>> [e-mail]
> > >>>> Subject: RE: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > >>>> cv
> > >>>> Importance: High
> > >>>>
> > >>>> Hi Eric,
> > >>>>
> > >>>> just one more to follow up. You say:
> > >>>>
> > >>>>> EG > 24 is correct for the Static LSP Sub-TLV (it is 6 words long,
> > >>>>> EG > even if the last two octets "Must be Zero").  The length of
> > >>>>> EG > the Static Pseudowire Sub-TLV - on the other hand - was made
> > >>>>> EG > longer by the addition of the 2-word AGI.  Nice catch!
> > >>>>
> > >>>> In RFC 4379, section 3.2, the MUST be Zero parts don't seem to be
> > >>>> included in the length of the sub-TLVs. Why are they included here?
> > >>>>
> > >>>> Best,
> > >>>>
> > >>>> Rolf
> > >>>>
> > >>>>
> > >>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > >>>> London W3 6BL | Registered in England 2832014
> > >>>>
> > >>>>
> > >>>>>
> > >>>>> EG > Apparently.
> > >>>>>
> > >>>>> Which return code to send when identifiers are wrong (Malformed echo
> > >>>>> request received?) or drop the packet.
> > >>>>>
> > >>>>> EG > Drop the packet, probably log the error, possibly run off
> > >>>>> EG > screaming into the night.  What does one do when one gets
> > >>>>> EG > something either not recognizably intended for one, or not
> > >>>>> EG > from a source that one recognizes?  From a security point
> > >>>>> EG > of view, we cannot require an implementation to reply to
> > >>>>> EG > the requester in this case (this is an attack vector for
> > >>>>> EG > all kinds of hate and discontent).  Nor can we forbid it.
> > >>>>>
> > >>>>> Using the per-interface model and say the DSMAP TLV did not match the
> > >>>>> ingress IF identifier, then should this request frame be dropped?
> > >>>>> Should we reply to the requestor? Can this way two answers be
> > >>>>> generated?
> > >>>>>
> > >>>>> Nit (section 2.1): s/mpls/MPLS/
> > >>>>>
> > >>>>> EG > Thanks.
> > >>>>>
> > >>>>>
> > >>>>> Best,
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> Rolf
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> > >>>>> London W3 6BL | Registered in England 2832014
> > >>>>>
> > >>>>>
> > >>>>>> -----Original Message-----
> > >>>>>> From: [e-mail] [mailto:[e-mail]] On
> > >>>> Behalf
> > >>>>> Of
> > >>>>>> Loa Andersson
> > >>>>>> Sent: Donnerstag, 16. Juni 2011 22:01
> > >>>>>> To: [e-mail]; [e-mail];
> > >>>>> Ross
> > >>>>>> Callon; George Swallow; MPLS-TP ad hoc team
> > >>>>>> Subject: [mpls] Verification call on draft-ietf-mpls-tp-on-demand-
> > >>>> cv
> > >>>>>>
> > >>>>>> Working Group.
> > >>>>>>
> > >>>>>> the authors of draft-ietf-mpls-tp-on-demand-cv have updated the ID
> > >>>>>> after wg last call and published version -04 of the document.
> > >>>>>>
> > >>>>>> A document detailing how the comments have been addressed will be
> > >>>>>> found at:
> > >>>>>> http://www.pi.nu/~loa/comments-on-03.xls
> > >>>>>>
> > >>>>>> This is to start a working group call to verify that all comments
> > >>>>>> been adequately addressed. Please send your comments to the
> > >>>>>> mpls working group mailing list before June 24th.
> > >>>>>>
> > >>>>>> Loa
> > >>>>>> on behalf of the MPLS wg co-chairs
> > >>>>>>
> > >>>>>> --
> > >>>>>>
> > >>>>>>
> > >>>>>> Loa Andersson                         email:
> > >>>>> [e-mail]
> > >>>>>> Sr Strategy and Standards Manager            [e-mail]
> > >>>>>> Ericsson Inc                          phone: [phone]
> > >>>>>>                                              [phone]
> > >>>>>> _______________________________________________
> > >>>>>> mpls mailing list
> > >>>>>> [e-mail]
> > >>>>>> https://www.ietf.org/mailman/listinfo/mpls
> > >>>>> _______________________________________________
> > >>>>> mpls mailing list
> > >>>>> [e-mail]
> > >>>>> https://www.ietf.org/mailman/listinfo/mpls
> > >>> _______________________________________________
> > >>> mpls mailing list
> > >>> [e-mail]
> > >>> https://www.ietf.org/mailman/listinfo/mpls
> > >
> > >
> > > _______________________________________________
> > > mpls mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mpls