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

[Eric Gray <[e-mail]>]

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