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

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

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